Methods and arrangements for prefix management in moving networks

ABSTRACT

The present invention relates to prefix management in a moving network comprising a first mobile router which is assigned a first prefix for use when passing traffic to and from a home agent with which the first mobile router is associated, and a second mobile router. The present invention relates to methods and arrangements in the first mobile router, the second mobile router and the home agent for delegating the right to use said first prefix to said second mobile router in a secure manner by means of first and second authentication information that may be compared to verify that the second mobile router has the right to use the first prefix.

FIELD OF THE INVENTION

The present invention relates to methods and arrangements in mobilecommunication systems, and more particularly, to methods andarrangements for management of prefixes used in moving networks.

BACKGROUND

A moving network is defined as a network that is movable in relation toits home network. A moving network can change its point of attachment toa fixed infrastructure or it may have many points of attachment to afixed infrastructure, but it is still able to communicate with a homenetwork through a mobile router having access to an external accessthrough which all communication nodes in the moving network cancommunicate. Such a communication node in a moving network is called amoving network node. In the case of a moving network on e.g. anairplane, the moving network will comprise communication nodes, whichmay be different users' communication devices, such as laptops, mobilephones, PDAs (Personal Digital Assistants) etc., which communicationnodes use wireless or wireline communication to communicate with amobile router within the airplane, such that all communication destinedto an external address will pass via the mobile router. A moving networkmay also be e.g. a Personal Area Network (PAN), wherein a PAN comprisesall communication devices belonging to a user and situated within shortrange radio communication distance from each other. In this application,each node in the moving network or connected to the moving network thatworks like a router for data originating from a moving network node anddestined to an address external of the moving network is defined as amobile router. Examples of such mobile routers are: a PAN device workingas a router in a PAN, and a router in a moving network on a vehicle.Note that a node may have both roles, i.e. being both a moving networknode and a mobile router, for example a PAN device such as a mobilephone in a PAN.

“The Network Mobility (NEMO) Basic Support Protocol”, by Devarapalli etal, published in January 2005 as a Request For Comments (RFC) 3963 bythe Internet Engineering Task Force, identifies a protocol that enablesa moving network to attach to different points in the Internet. Theprotocol is an extension of Mobile IPv6, and allows session continuityfor every communication node (or communication device) in the movingnetwork as the moving network moves. It allows a mobile router tomaintain a stable network address prefix for a moving network, even asthe mobile router changes its, and thus the moving network's, point ofattachment to a fixed network infrastructure. This prefix stability isachieved through a solution similar to the Mobile IPv6 solution, i.e. bymaking a home agent (HA) in the home network of the mobile router afixed point of presence for the Mobile Router (MR) and maintainingconnectivity between the HA and the MR through a tunnel. The addressprefix, which is called Mobile network prefix (MNP) in the NEMOprotocol, is allocated from the address range of the home network, andcan thus remain the same even as the MR and its network move. When theMR attaches to a network in a new location, it acquires a new care-ofaddress in the new network, which care-of address is used to locate theMR in the new network, but its home address and address prefix areunchanged. However, just like in Mobile IPv6 the MR has to register itsnew care-of address in the HA in order to maintain the tunnel betweenthe Mobile Router and the Home Agent.

The nodes belonging to the network cluster that moves along with themobile router are called Mobile Network Nodes (MNNs). In the NEMO basicsupport protocol they will not change their configuration as the MRchanges its point of attachment. In other words, the mobility istransparent to them.

Presently the NEMO basic support protocol allows only a single care-ofaddress to be registered in the HA for a certain MR at any one time.Multiple simultaneous care-of addresses are not allowed and thusmultiple simultaneous accesses and MR-HA tunnels are not possible for aMR. Under these conditions, it may support one or multiple MNPs in themoving network. Although the protocol does not exclude multiple MRs in amoving network, it has no explicit support for it and it does notaddress the issues and problems that arise when multiple MRs, usingdifferent MNPs or prefixes, are present in a moving network.

One problem with multiple MRs in a moving network is that all MRs mayadvertise themselves as default routers. Then an MNN will arbitrarilyselect one of the MRs for sending default route traffic to. This mayconflict with flow management policies that may be defined for the MRs,as a certain policy may indicate that a particular flow should be routedover a specific access that belongs to another MR than the one the MNNselected. Furthermore when the MNN hears the advertisement of twodefault routers announcing two different prefixes it will configure twoaddresses and set its default route arbitrarily to either of the MRs, sothat all traffic is routed via this MR, even traffic that is associatedwith the prefix of the other MR. As a result problems with ingressfiltering may arise as will be discussed further below.

The multiple MRs of the moving network may offer external network accessusing different access technologies e.g. GPRS, WCDMA and satellite.Different access technologies may be accessible over different MRssimultaneously so that it is possible to select the access to be usedfrom among a number of possible accesses. Access selection policies maybe implemented in the moving network or the end-user may be allowed toinfluence the choice of access. In order to be able to choose freelybetween the different available external accesses a packet should beallowed to exit the moving network via the particular MR that isconnected to the preferred access. However if ingress filtering is usedin the network this may restrict the access selection or cause aconflict between access selection and source address selection in thenetwork.

Ingress filtering is used to stop incorrect (or malicious) packets. Itis performed by (arbitrary) routers by inspecting that the sourceaddress used in packets leaving a network (upstream, towards theInternet) is topologically correct. The router knows what address spaceis used below itself and only packets with a source address from thataddress space should be let through. Therefore a packet with a certainsource address may have to exit the moving network via the MR thatsupports the prefix of the source address in order to avoid ingressfiltering, instead of via the MR that is connected to the preferredaccess. A conflict arises between source address selection and accessselection when ingress filtering requires that a packet exit a movingnetwork via a MR that supports the prefix of the source address of thepacket and the access selection policies used in the moving networkindicate that another access should be used for the packet than the onesthat are available from the MR that supports the prefix of the sourceaddress. Thus, there is a dependency between source address selectionand access selection, which may result in conflicts.

Another problem which may arise in moving networks with multiple MRsusing different prefixes is that it may be difficult to maintain prefixconsistency if the moving network is involved in splits or merges,especially if the MRs use different HAs. The nature of a moving networkis often inherently dynamic. This does not only mean that availableexternal accesses come and go as the moving network moves, disconnectsand reconnects, but also that the moving network may split into separatemoving networks or merge with another moving network and that the MRsthat are present in the moving network may change at any time.

The mechanisms described in the Internet-Draft “Token based DuplicateNetwork Detection for split mobile network (Token based DND)” by M.Kumazawa et al., published in July 2005, allow multiple MRs (notoriginally using the same prefix) to support each other's prefix if theyshare the same HA. The solution is based on a token that is associatedwith a prefix. It distinguishes between the “owner” and a “borrower” ofa prefix. The MR that owns the prefix generates the token and sends itto the HA in the BU and then includes it in its Router Advertisements.If another MR subsequently sends a BU with the same prefix in the MobileNetwork Prefix option it has to include the token associated with theprefix (assumedly received in a Router Advertisement from the owner ofthe prefix). The HA compares the prefix and token with the ones it haspreviously stored and if they match, the MR is accepted as a borrower ofthe prefix. If the MR fails to supply this token or supplies anothertoken, the HA will not accept the MR as a borrower of the prefix.

A shortcoming of the solution described in the above mentionedInternet-Draft is that it is limited to scenarios when the involved MRsshare the same HA. Another significant problem is that the MR that ownsthe prefix has no control over which MRs that borrows the prefix. Any MR(using to the same HA) that receives the broadcast token will be able touse the prefix associated with the token after contacting the HA. Thesolution is insecure, because it lacks protection against maliciousnodes (MRs or MNNs) pretending to be the owner of a prefix. Hence amalicious node may e.g. falsely update the token, or replay a correcttoken in a moving network where the rightful owner of the prefix is notpresent, thus interfering with the correct prefix usage and potentiallycreating prefix inconsistencies with the same prefix in use in differentmoving networks.

The Internet-Draft “Neighbor MR Authentication and RegistrationMechanism in Multihomed Mobile Networks” by Seongho Cho et al.,published in April 2004, describes a solution that allows a MR toforward packets to and from the HA of a neighbor MR, wherein the sourceaddress of a forwarded packet has a prefix supported by the neighbor MR.The purpose is to enable that neighboring MRs can be used to providealternative paths for fault recovery and/or load sharing. The RouterAdvertisements are extended with the home address (HoA) and care-ofaddress (CoA) of the sending MR. A MR gathers information about itsneighboring MRs by listening to Router Advertisements and collecting theHoA, CoA and MNP of each identified neighbor MR. The retrieved HoA andCoA are “authenticated” through the return routability test of MIPv6,but the validity of the MNP is not verified. During the returnroutability test the MR also retrieves the HA address of a neighboringMR. A MR reports the retrieved neighbor information to its HA throughextensions to the BU. The HA can then use this information to establishan alternative bi-directional tunnel to a neighbor MR to provideredundancy for fault recovery and/or load sharing.

The most serious deficiency of the solution described in theInternet-Draft “Neighbor MR Authentication and Registration Mechanism inMultihomed Mobile Networks” is that it does not enable a securityrelation between the HA and the neighbor MR. Thus, the HA will not beable to authenticate this MR and the signaling between the HA and thisMR will be unprotected as well as the traffic in the bidirectionaltunnel. Moreover, the “authentication” of the neighbor information isdeficient. It verifies the binding between the CoA and the HoA, but itdoes not verify that they belong to the MR that announces theseaddresses in its Router Advertisements. This means that an attackercould first find out CoA and HoA of another MR (which may be locatedanywhere) and then announce these parameters in a false RouterAdvertisement. Listening MRs would not be able to detect that theinformation is false, since the return routability test would succeed.Thus, the neighbor MRs as well as their respective HAs would be fooledby the attacker.

The mechanisms described in the document “IPv6 Multihoming Support atSite Exit Routers” by Hagino, J et al., published in October 2001 asRequest For Comments 3178 by the by the Internet Engineering Task Force,provide redundancy and prefix support to fixed exit routers that areprimarily/originally connected to different ISPs. The solution addressesthe problem of achieving redundant connectivity from a multi-homed fixedsite having multiple ISPs by establishing fall-back links between siteedge routers and the ISPs.

The solution described in the aforementioned document is a purelyconfiguration-based solution for fixed networks and it is not directlyapplicable to moving networks.

SUMMARY OF THE INVENTION

Some problems and difficulties which may arise when a moving networkincludes several mobile routers using different prefixes have beendiscussed above. An object of the present invention is to providemethods and arrangements that allow for improved prefix management in amoving network with multiple mobile routers using different prefixes.

The above stated object is achieved by means of a first mobile router, asecond mobile router, a home agent, a communications system, a method ina first mobile router, a method in a second mobile router and a methodin a home agent, having the features defined in the independent claims.Preferred embodiments are defined in the dependent claims.

The basic idea of the present invention is to provide methods andarrangements that support delegation of the right to use a prefix fromone mobile router, which has been assigned the prefix, to another mobilerouter in a moving network. Implementation of the basic idea of thepresent invention requires new methods and arrangements, which are allprovided according to different aspects of the present invention.

According to a first aspect the present invention provides a method forprefix management in a first mobile router of a moving network. Thefirst mobile router is assigned a first prefix for use when passingtraffic to and from a home agent with which the first mobile router isassociated. The method comprises establishing a communicationsconnection with a second mobile router of the moving network. The methodfurther comprises delegating the right to use the first prefix to thesecond mobile router by transferring first prefix delegation informationto the home agent and transferring second prefix delegation informationto the second mobile router over said communications connection, whichfirst and second prefix delegation information includes first and secondauthentication information respectively that may be compared to verifythat the second mobile router has the right to use the first prefix.

According to a second aspect the present invention provides a method forprefix management in a second mobile router of a moving network. Themethod comprises establishing a communications connection with a firstmobile router of the moving network. The first mobile router is assigneda first prefix for use when passing traffic to and from a home agentwith which the first mobile router is associated. The method furthercomprises receiving second prefix delegation information from the firstmobile router over the communications connection delegating the right touse the first prefix to the second mobile router, which second prefixdelegation information includes second authentication information thatmay be compared to first authentication information to verify that thesecond mobile router has the right to use said first prefix. The methodalso includes sending a request for prefix delegation utilization to thehome agent which utilization request includes the second authenticationinformation and establishing a bidirectional tunnel for passing trafficbetween the second mobile router and the home agent using the firstprefix.

According to a third aspect, the present invention provides a method ina home agent having an associated first mobile router of a movingnetwork. The first mobile router is assigned a first prefix for use whenpassing traffic to and from the home agent. The method comprises thestep of receiving first prefix delegation information from the firstmobile router delegating the right to use the first prefix to a secondmobile router of the moving network. The first prefix delegationinformation includes first authentication information. The methodfurther comprises the step of receiving a request for a prefixdelegation utilization from the second mobile router. The utilizationrequest includes second authentication information. Yet a further stepof the method includes authorizing the prefix delegation of the firstprefix to the second mobile router if a comparison of the firstauthentication information and the second authentication informationverifies that the second mobile router has the right to use the firstprefix. The method also includes the step of establishing abidirectional tunnel for passing traffic between the second mobilerouter and the home agent using the first prefix if the prefixdelegation was authorized.

According to a fourth, fifth, sixth and seventh aspects the presentinvention also provides a first mobile router, a second mobile router, ahome agent and a communications system that can be used to perform themethods according to the first, second and third aspect of the presentinvention.

An advantage of the present invention is that it can be used to ensurethat all MRs in a moving network consistently support the sameprefixes—even when the MRs use different HAs.

Another advantage of the present invention is that it allows a movingnetwork to benefit from the advantages of multi-homing, e.g. pathredundancy, even when the multi-homing is achieved through multiple MRsusing different MNPs.

Yet another advantage of the present invention is that it enablesdecoupling of source address selection from external access selection,thus facilitating efficient and consistent flow management mechanisms ina moving network with multiple MRs and multiple MNPs. Using the presentinvention, MNNs can freely select source address while ingress filteringrules are honored and flow management policies (i.e. rules for externalaccess selection per flow) are still followed.

A further advantage of the invention is that it can be used to maintainprefix consistency and functioning routing in moving networks that gothrough splits and/or mergers.

Yet a further advantage of the present invention is that is has noimpact on the MNNs in terms of new requirements on functions orbehavior. The solution is implemented solely in the involved MRs andHAs. This is an important property of the invention to avoid backwardscompatibility problems and other deployment problems, since potentialMNNs are numerous and hard to control in terms of implemented software,whereas MRs and HAs are few and assumedly under administrative control.

Further advantages and features of embodiments of the present inventionwill become apparent when reading the following detailed description inconjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram of a Vehicle Area Network (VAN) inwhich the present invention may be used.

FIG. 2 is a schematic diagram illustrating a first phase of anembodiment of a prefix delegation procedure.

FIG. 3 is a schematic diagram illustrating a second phase of theembodiment of the prefix delegation procedure.

FIG. 4 is a schematic diagram illustrating a third phase of theembodiment of the prefix delegation procedure.

FIG. 5 is a schematic diagram illustrating a fourth phase of theembodiment of the prefix delegation procedure.

FIG. 6 is a schematic diagram illustrating a fifth phase of theembodiment of the prefix delegation procedure.

FIG. 7 is a schematic diagram illustrating an alternative fifth phase ofthe embodiment of the prefix delegation procedure.

FIG. 8 is a schematic block diagram of another Vehicle Area Network(VAN) in which the present invention may be used.

FIG. 9 is a schematic block diagram of a Personal Area Network (PAN) inwhich the present invention may be used.

FIG. 10 is a schematic block diagram of another Personal Area Network(PAN) in which the present invention may be used.

DETAILED DESCRIPTION

The present invention now will be described more fully hereinafter withreference to the accompanying drawings, in which preferred embodimentsof the invention are shown. This invention may, however, be embodied inmany different forms and should not be construed as limited to theembodiments set forth herein; rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the scope of the invention to those skilled in the art. In thedrawings, like numbers refer to like elements.

The present invention is applicable in moving networks having multiplemobile routers (MRs) using different prefixes. An example of a movingnetwork in which the present invention may be implemented is illustratedin FIG. 1 which shows a Vehicle Area Network (VAN) 101 within a publictransportation vehicle (e.g. a bus, a train, an airplane). The internalnetwork 102 within the vehicle can be some sort of switched Ethernetwith both Ethernet ports and WLAN access points 103 deployed. Theinternal network also has multiple MRs 104, 105 which act as gatewaysfor external communication for all mobile network nodes (MNNs) 106, 107inside the vehicle. The MRs are also responsible for mobility managementfor the entire network, i.e. mobility management is totally transparentto the MNNs entering the vehicle. The external network accesses 108,109, 110 from the vehicle are based on one or several different accesstechnologies, e.g. General Packet Radio Service (GPRS), Wideband CodeDivision Multiple Access (WCDMA), and satellite. Several of theseaccesses can be available at the same time depending on for instancecoverage and operator policies. FIG. 1 also shows the home network 111and the home agent (HA) 112 that the MRs are communicating with via anexternal IP network 113. The MRs 104, 105 need to establish one tunnelto the HA 112 for each available external access. The example in FIG. 1shows three tunnels 114, 115, 116 from the MRs (two from the MR 104, onefrom the MR 105) to the HA 112. The MRs may share the same HA and thesame prefix from the address range of the home network, but it is alsopossible that the MRs have different prefixes and possibly alsodifferent HAs. The present invention may be useful in scenarios wherethe MRs have different prefixes.

The basic concept of the present invention is that a MR is allowed todelegate its right or authority to use a certain prefix to another MR.The MR that delegates its right to use one or more of the prefixes willhereinafter be referred to as a delegating MR and the MR that receivesthe delegated right to use one or more prefixes will hereinafter bereferred to as a receiving MR. To enable the receiving MR to use thedelegated right the delegating MR also delegates a MR-HA relation to thereceiving MR, or, in other words, bootstraps the receiving MR and the HAwith the data and credentials required for a security relation as willbe explained in further detail below. The prefix delegation of thepresent invention provides the receiving MR with the ability to supportthe prefix of the delegating MR and use the delegating MR's HA fortraffic to and from the moving network.

For the understanding of the following detailed description of thepresent invention and different embodiments the interpretation of anumber of terms are important:

The term “prefix right delegation” or shorter “prefix delegation” willin this application be used to refer to the act performed by adelegating MR to delegate to another receiving MR the right to use oneor more address prefixes. After a prefix right delegation has beencompleted, both the delegating MR and the receiving MR can support thedelegated prefix or prefixes.

The MR that has been assigned a certain prefix by its own right (i.e.not using a delegated right) will herein be referred to as a “primaryprefix holder”. Examples of this kind of prefix assignment are prefixassignment between the MR and its HA or home network, and staticconfiguration of a prefix in the MR.

A MR that has been assigned a certain prefix based on a delegated rightwill herein be referred to as a “secondary prefix holder”.

The term Home Agent (HA) used in the application should be interpretedas any node in a home network working like a mobile anchor point to themoving network, i.e. facilitating communication from the moving networkover an external network and the home network.

A MR is herein said to “belong” to a HA if it has a regular (i.e. notresulting from a delegation) security relation with the HA. A HA's MRsare the set of MRs that belong to the HA.

The term Internet Key Exchange (IKE) is herein used to refer to eitherversion 1 (IKEv1), version 2 (IKEv2) or future versions or equivalentsof the protocol.

In the world of communication technologies the term credentials issometimes used to refer to an identity and data associated with theidentity, which data is used to prove the authenticity of the identity(or proof of identity ownership with other words). Other times the termcredentials refer only to said data associated with the identity, butexcluding the identity itself. In this document the latter meaning ofthe term is used, i.e. the term credentials refers to data that isassociated with an identity and which is used for proving ownership orauthenticity of this identity. Examples of credentials includepre-shared key, cryptographic key certificate, password, PIN code, etc.In addition, the term “set of credentials” is herein used as theequivalence of credentials and may consist of a single or several piecesof data.

In order to implement the present invention the delegating MR, thereceiving MR and the HA need to be adapted to be able to handle prefixdelegations in accordance with the present invention. The delegating MRwill have to transfer certain prefix delegation information to thereceiving MR and to the HA. The delegation information that thereceiving MR and the HA receive from the delegating MR differs indifferent embodiments of the invention. The prefix delegationinformation that is sent to the receiving MR may be the same informationthat is sent to the HA or it may differ. However both the prefixinformation that is sent to the receiving MR and the prefix informationthat is sent to the HA must include authentication information that canbe compared to verify that the receiving MR has the right to use thedelegated prefix. The authentication information may e.g. be adelegation MR-ID and a set of credentials. The delegation MR-ID isidentity information that the delegating MR generates and which is usedto identify a particular prefix delegation. In other words, thedelegation MR-ID is an identity that the delegating MR generates andwhich is to be used as an identity by a receiving MR, in place of thereceiving MR's regular identity, when communicating with the HA of thedelegating MR in conjunction with a certain delegation. The set ofcredentials may for instance be a pre-shared key, a certificate, apassword, a pin code or similar that is associated with the delegationMR-ID. The delegation MR-ID and the set of credentials are used tocreate a security relation between the receiving MR and the HA. Notethat the term “set of credentials” as used herein may consist of asingle piece of information such as a pre-shared key or may includeseveral pieces of information that may be used to authenticate theprefix delegation.

According to embodiments of the present invention the HA and thereceiving MR are arranged to store data associated with prefixdelegations in a HA delegation context and a receiving MR delegationcontext respectively.

The HA delegation context is a set of data stored in the HA. The dataincludes the information that is required to manage the delegation andto interact with the delegating MR and the receiving MR in the contextof the delegation. The HA delegation context may e.g. include:

-   -   The identity of the delegating MR (e.g. Network Access        Identifier (NAI) or Home Address (HoA)).    -   The delegated prefix(es).    -   The lifetime of the delegation (normally set to expire        simultaneously with the delegating MR's binding in the HA).    -   A delegation MR-ID (to be used as identity by the receiving MR        during e.g. an Internet Key Exchange (IKE) procedure towards the        HA).    -   A pre-shared key (or other set of credentials associated with        the delegation MR-ID).    -   Possibly a delegation ID.    -   A determined trust level. This is needed only if the HA gives        differential treatments to delegations with different trust        levels.    -   Possibly the HoA of the receiving MR. (This is preferably the        receiving MR's own (regular) HoA, but it is also possible that        it is a HoA assigned by the HA itself or by the delegating MR.        In the latter two cases it would be an address from the address        range of the HA's network). It is not necessary to include the        HoA of the receiving MR in the HA delegation context, since it        will anyway be included in the HA's data record for the binding        between the receiving MR's Care-of Address (CoA) and HoA.

The receiving MR delegation context is a set of data stored in thereceiving MR. The data includes information needed by the receiving MRto be able to use the delegation, i.e. to interact in a useful mannerwith the HA that is responsible for the delegated prefix(es). Thereceiving MR delegation context may e.g. include:

-   -   The delegated prefix(es).    -   The lifetime of the delegation (normally set to expire        simultaneously with the delegating MR's binding in the HA).    -   The address of the HA that is responsible for the delegated        prefix(es).    -   A delegation MR-ID (to be used as identity by the receiving MR        during e.g. an IKE procedure towards the HA).    -   A pre-shared key (or other set of credentials associated with        the delegation MR-ID).    -   Possibly the identity of the delegating MR (e.g. NAI or Internet        Protocol (IP) address).    -   Possibly a delegation ID.    -   Possibly the HoA associated with the delegation, in case a HoA        was received from the delegating MR.

According to the present invention a delegating MR is allowed todelegate its right/authority to use a certain prefix to anotherreceiving MR. This delegation should normally only be valid while thetwo MRs are present in the same moving network. To enable the receivingMR to use the delegated right the delegating MR also delegates a MR-HArelation to the receiving MR, or, in other words, bootstraps thereceiving MR and the HA with the data and credentials required for asecurity relation. The receiving MR can then support the prefix of thedelegating MR and use the delegating MR's HA for traffic (using theconcerned prefix) to and from the moving network. If desired, the rolesof the two MRs can then be reversed (resulting in “cross-delegation” ofprefix rights), so that both MRs support each other's prefixes. Thisallows the MRs to support a consistent set of prefixes for the benefitof all the nodes in the moving network.

The prefix right delegation according to an embodiment of the presentinvention comprises five phases:

-   -   Phase 1: Request of prefix right delegation.    -   Phase 2: Identify the receiving MR, determine trust level and        establish secure communication between MRs.    -   Phase 3: Delegation.    -   Phase 4: Utilization.    -   Phase 5: Revocation.

The above five phases are elaborated in more detail below.

Phase 1: Request of Prefix Right Delegation

Phase 1 is illustrated by means of a schematic block diagram in FIG. 2.FIG. 2 illustrates a home agent (HA) 201, a receiving mobile router(R-MR) 202 and a delegating mobile router (D-MR) 203. In this firstphase the potential receiving MR may request another (potentialdelegating) MR to delegate the right to use a certain prefix or prefixesin a step 204. This action may have been triggered by detection of thepresence of the other (potential delegating) MR, and its prefix(es), inthe moving network. The potential delegating MR responds with a positiveor negative acknowledgement message in a step 204 a.

This is an optional phase that may be omitted. In such case the wholedelegation procedure begins when the potential delegating MR initiatesphase 2.

Phase 2: Identify the Receiving MR, Determine Trust Level and EstablishSecure Communication Between MRs

If phase 1 is skipped, this is the first phase. Phase 2 is illustratedschematically in FIG. 3. In this phase the potential delegating MRdetermines the level of trust towards the potential receiving MR andestablishes secure communication. The trust level may be determined byexchanging identities and comparing the identity of the other MR withinternal (or external) configuration data, step 205. The identities maye.g. be exchanged and authenticated in the context of an Internet KeyExchange (IKE) procedure, which results in established IPsec SecurityAssociations (Ipsec SAs) as defined in RFC 2401 “Security Architecturefor the Internet Protocol”, published in November 1998, and itssuccessor RFC 4301 with the same name, published in December 2005 by theInternet Engineering Task Force. The IPsec SAs can be used for securecommunication between the MRs. Alternatives to IKE/IPsec include e.g.Transport Layer Security (TLS). In a personal area network (PAN)scenario PAN specific protocols, such as the PAN Management Protocol(PMP) described in the international patent application WO2006/001736could also be used to determine the trust level and establish securecommunication.

If the potential delegating MR cannot authenticate the identity of thepotential receiving MR, thus probably implying the lowest trust level,it may still choose to establish secure communication (e.g. throughIPsec SAs or using TLS) to the potential receiving MR and to delegatethe right to use one or more of its prefixes. This is a matter of policyand configuration, and possibly even user interaction. It should benoted that it is quite possible to establish secure communicationbetween two nodes that are unknown to each other and lack a prearrangedsecurity relation using the Diffie-Hellman key exchange procedure.

Phase 3: Delegation

In this phase the delegating MR transfers the information that isrequired for a prefix right delegation to the receiving MR and to theHA. The required information will depend on the particularimplementation of the invention and may thus differ between differentembodiments of the invention. However both the delegation informationthat is sent to the HA and the delegation information that is sent tothe receiving MR will include authentication information such as adelegation MR-ID to be used as identity information identifying theparticular delegation and a set of credentials associated with thedelegation MR-ID, such as a pre-shared key. In this example thedelegating MR transfers to the receiving MR the information needed toestablish the receiving MR delegation context discussed above. To the HAit transfers the information needed to establish the HA delegationcontext. Note that this does not have to include the HoA of thereceiving MR. The receiving MR may instead provide the HoA in a BindingUpdate (BU) that it, according to NEMO basic support protocol, RFC 3963,needs to send to the HA to be able to use the prefix (see phase 4). TheHoA is not even an indispensable part of the HA delegation context,since it instead may be included in the HA's data record for the bindingbetween the receiving MR's CoA and HoA.

Phase 3 is illustrated schematically in FIG. 4. When transferringinformation to the HA 201 in a step 206, the delegating MR 203 may use aBU with the delegation related information included in a new (backwardscompatible) mobility option. Another possibility would be to use acompletely new type of message. The HA 201 may acknowledge the receptionof the delegation information by means of sending a BindingAcknowledgement (BA) or a new type of acknowledgement message to thedelegating MR in a step 207.

At this point the HA 201 is the instance that ultimately authorizes thedelegation and the receiving MR's right to use the concerned prefix. TheHA 201 may have been given the right by an administrator to override thedelegation. This is a quite natural arrangement, because the prefixbeing delegated can be seen as owned by the HA or a node in the homenetwork. The prefix has been delegated further to the delegating MR 203in the first place, e.g. as part of a service subscription model. It ispossible that the HA 201 does not accept further delegation of a certainprefix or by a certain delegating MR. It is also possible that the HAdoes not accept delegation to a certain receiving MR 202. In addition,the HA 201 may not accept too low levels of trust between the delegatingMR 203 and the receiving MR 202. A malicious receiving MR may harm thedelegating MR (e.g. by traffic interception), but it may also harm theHA to some degree. Therefore it is preferable that the delegating MRinforms the HA about the level of trust between the two MRs. Thedelegating MR may also inform the HA about the method of trustdetermination and the way the credentials were generated and transferredto the receiving MR. The HA may use such information to refine the trustlevel determination.

All these criteria for delegation authorization may be based ondelegation policies configured in the HA 201 or retrieved from somerepository (e.g. an Authentication, Authorization and Accounting (AAA)server).

An alternative conceptual model would be that the prefix actually isowned by the delegating MR 203 in the first place and not by the HA 201.Prefix ownership would then come from the leaves, not from the center(root) of the network. With this model the HA 201 should not be able tooverride a delegation from a rightful owner of a prefix. The HA wouldnot be the authority point in this context—only a mobility function.

The delegating MR may transfer the delegation information to thereceiving MR by means of a new type of message or possibly an existinggeneric information transfer protocol such as File Transfer Protocol(FTP) in a step 208. An alternative could be to use a PAN specificprotocol like the PAN Management Protocol (PMP) mentioned above. Thereceiving MR may acknowledge reception of the delegation information ina new message type in step 209.

It is often preferred that the delegating MR 203 transfers informationto the HA 201 before transferring information to the receiving MR 202.If the HA 201 does not accept the delegation, it indicates this in theresponding BA and the delegating MR 203 in turn informs the intendedreceiving MR 202 of the failure. Transferring delegation information tothe HA 201 before the receiving MR 202 also allows the delegating MR 203to set the lifetime of the delegation to the lifetime received in the BAfrom the HA 201. In addition, if the HA 201 assigns a HoA for thedelegation, this has to be conveyed to the delegating MR in the BA,possibly included in a new (backwards compatible) mobility option, or ina new type of message before the delegating MR 203 can transfer it tothe receiving MR 202.

The delegating MR 203 may later extend the lifetime of the delegationusing the Binding Update procedure (or new message types), steps 210 and211. After such a lifetime extension the delegating MR 203 may alsoupdate the delegation lifetime in the receiving MR 202 (using newmessage types, e.g. the same messages types as for the initialdelegation), steps 212 and 213. The delegating MR may use the samemethod for other types of delegation updates, such as adding or removingone or more prefix(es) from/to the delegation.

Phase 4: Utilization

Phase 4 is illustrated in FIG. 5. According to the present example thereceiving MR 202 establishes IPsec SAs with the HA 210 through IKE(version 1 or 2) procedures using the received authenticationinformation, in this example a delegation MR-ID and associatedpre-shared key (or other set of credentials), in step 214. In this stepthe HA will receive a delegation MR-ID and proof of possession of itsassociated set of credentials, e.g. a pre-shared key, from the receivingMR and check that these matches the delegation MR-ID and set ofcredentials received from the delegating MR. In other words the HAcompares the authentication information received from the delegating MRwith authentication information received from the receiving MR to verifythat the receiving MR has the right to use the delegated prefix. It isalso possible to use another authentication and IPsec SA establishmentprocedure than the IKE procedure, but in order to provide the increasedsecurity and protection against malicious nodes it is important that theHA checks that the authentication information, such as a delegationMR-ID and set of credentials, from the delegating MR matches theauthentication information from the receiving MR. Matching delegationMR-IDs and sets of credentials will in most cases mean that thedelegation MR-IDs and sets of credentials are identical respectively,which is verified by the authentication algorithm. However it is alsopossible that the sets of credentials are not identical and that aspecific algorithm must be used to determine if the delegation MR-IDsand sets of credentials match. The sets of the credentials of thereceiving MR and the delegating MR may for instance be the matching keysof a private-public key pair. In another possible embodiment acertificate may be used to verify that the receiving mobile router isallowed to use the delegated prefix. The delegating MR may then issue acertificate that is associated with a delegation MR-ID and aprivate-public key pair, and the delegation MR-ID, the private-publickey pair and the certificate are then transferred to the receiving MR-IDas authentication information. Assuming that the HA is already aware ofa public key associated with the delegating MR the delegating MR will inthat case only have to transfer the delegation MR-ID as authenticationinformation to the HA. The HA may then use the public key of thedelegating MR to verify the certificate and thus also verify that thereceiving MR is allowed to use the delegated prefix.

Provided that the authentication procedure was successful, the receivingMR 202 and the HA 201 then act in accordance with the NEMO Basic Supportprotocol. That is, the receiving MR registers in the HA through aBinding Update procedure and establishes a bidirectional tunnel. In FIG.5 step 215 illustrates that the receiving MR 202 sends a BU to the HA201 and step 216 illustrates that the HA sends a BA to the receiving MR.The HA and the receiving MR then use the bidirectional tunnel to passtraffic (illustrated by the arrow denoted 217 in FIG. 5) using thedelegated prefix(es) in the source or destination address to and fromthe moving network.

Optionally the HA may update the lifetime of the delegation in a new(backwards compatible) mobility option in the BA 216. If the BA does notinclude an explicit delegation lifetime value, the receiving MR may setthe delegation lifetime to the maximum of the currently stored remainingdelegation lifetime and the lifetime of the binding received in the BA.When the binding is about to time out it is possible that the binding isrefreshed by means of another BU, step 218 and another BA, step 219,updating the delegation lifetime.

As with any Binding Update procedure, the HA 201 has the possibility toreject the BU (and indicate this in the BA). When the BU concerns adelegated prefix, a reason for the HA to reject the BU could be that thecircumstances around the delegation has changed, e.g. because of updateddelegation policies, so that the HA can no longer accept the delegation.

When the receiving MR has established the bidirectional tunnel and isfinally capable of (and authorized to) use the delegated prefix(es), itincludes the concerned prefix(es) in its Router Advertisements.

Phase 5: Revocation

In this example the prefix delegation has a limited, but extendable,lifetime. The delegation can also be explicitly revoked. In phase 5 thedelegation is revoked, either explicitly or implicitly. The revocationmay be initiated by the delegating MR as illustrated schematically inFIG. 6 (including different options) or by the HA as illustratedschematically in FIG. 7 (including different options). In the formercase the delegating MR revokes the delegation by informing the HA (e.g.by setting the delegation lifetime to zero) in a step 222 and maybe, ifpossible, also informing the receiving MR in a step 220. Otherwise theHA will inform the receiving MR in a step 224, either immediately, usinga new type of message or a MIPv6 Binding Error (BE) message, or the nexttime the receiving MR tries to use the delegation context (i.e. anyaction belonging to the utilization phase), using a BA or possibly a newtype of message. In FIG. 6 step 221 illustrates an acknowledgment ofrevocation that is sent from the receiving MR to the delegating MR ifthe revocation message sent in step 220 was received. Step 223illustrates a BA or possibly a new type of acknowledgment message sentfrom the HA to the delegating MR to acknowledge receipt of a BU or othermessage comprising an indication of a revocation of the prefixdelegation.

The HA may inform, step 224, the receiving MR of a revocation in manydifferent ways as illustrated in FIG. 6. If the delegating MR did notinform the receiving MR of the revocation or if no acknowledgement wasreceived from the receiving MR in step 221 the HA may revoke the prefixdelegation in a new message type or a BE sent in step 224 a. Thereceiving MR may acknowledge reception of this revocation message instep 224 b, unless the message sent in step 224 a was a BE. Anotheroption is to let the HA inform the receiving MR the next time itreceives a data packet sent through the bidirectional tunnel associatedwith the prefix delegation. Step 224 c illustrates that the receiving MRsends a data packet through the bidirectional tunnel. Step 224 dillustrates that the HA responds by sending a message, a BE or a newtype of message, revoking the delegation to the receiving MR, which inturn acknowledges the revocation message in a step 224 e, unless themessage sent in step 224 d was a BE. Yet another option is that when thereceiving MR sends a BU to refresh or update the binding in the HA, step224 f, the HA sends a BA rejecting the BU which indicates revokeddelegation as the cause, step 224 g.

A possible reason for a delegating MR to revoke a prefix delegationcould be e.g. that it discovers that the receiving MR is no longerconnected to the same moving network.

The HA may also initiate the revocation. A possible reason for the HA torevoke a delegation could be that the delegating MR's binding is deleted(although it is not certain that this is reason enough in someembodiments). Other reasons may for instance be administrative reasons,e.g. general policy changes or changes in the delegating MR's right touse the concerned prefix or its right to delegate. That the delegatingMR's binding times out in the regular way (due to lack of refreshingBinding Updates) should normally not trigger a revocation, since thelifetime of the delegation normally should not have been set to agreater value than the lifetime of the delegating MR's binding in thefirst place.

Now turning to FIG. 7. When the HA initiates the revocation it informsthe receiving MR in a step 225 either immediately, using a new type ofmessage or a MIPv6 Binding Error (BE) message, or the next time thereceiving MR tries to use the delegation. The HA may also inform thedelegating MR in a new type of message, step 226. The delegating MR mayacknowledge reception of the revocation message in a step 227. The HAmay inform, step 225, the receiving MR of a revocation in many differentways as illustrated in FIG. 7. The HA may revoke the prefix delegationin a new message type or a BE sent in step 225 a. The receiving MR mayacknowledge reception of this revocation message in step 225 b, unlessthe message sent in step 225 a was a BE. Another option is to let the HAinform the receiving MR the next time it receives a data packet sentthrough the bidirectional tunnel associated with the prefix delegation.Step 225 c illustrates that the receiving MR sends a data packet throughthe bidirectional tunnel. Step 225 d illustrates that the HA responds bysending a message, e.g. a BE or a new type of message, revoking thedelegation to the receiving MR, which in turn acknowledges therevocation message in a step 225 e, unless the message sent in step 225d was a BE. Yet another option is that when the receiving MR sends a BUto refresh or update the binding in the HA, step 225 f, the HA sends aBA rejecting the BU which BA indicates revoked delegation as the cause,step 225 g.

As mentioned above the HA may use the MIPv6 Binding Error message toinform a receiving MR of a revoked delegation. The Binding Error messageis normally used only by correspondent nodes (i.e. when MIPv6 routeoptimization is used) and not by HAs. Still, with a new status codeindicating “Revoked delegation(s)” the message would serve this newpurpose well. If the HA has stored only one delegation associated withthe concerned delegation MR-ID (and delegating MR identity), then thisnew status code is the only required addition to the existing BindingError message format. This can be generalized to the case when the HAhas stored multiple delegations associated with the concerned delegationMR-ID (and delegating MR identity), in which case the Binding Errormessage would indicate revocation of all these delegations. However, inorder to allow the HA to revoke only a subset of multiple delegationsassociated with the concerned delegation MR-ID (and delegating MRidentity), the new status code is not enough. In addition, the BindingError must include information that identifies the delegations that arerevoked. This information is preferably included in a new mobilityoption or multiple instances of the same new mobility option containingone delegation identification each. The same or similar status code anddelegation identification can be used if the HA uses a BA to indicatethe revocation.

Phase 5 is optional. If not explicitly revoked, the prefix delegationwill sooner or later time out due to lack of refreshing Binding Updates(or other refreshing messages).

There are potentially several alternative ways to identify a specificdelegation, the choice of which impacts the properties of the solutionin general. If a delegation MR-ID is used as part of the authenticationinformation sent to the HA and the receiving MR one may choose to thedelegation MR-ID as a pure node (MR) identifier or as a delegationidentifier. Another choice, which has less impact, is whether to use aseparate delegation ID.

If the delegation MR-ID is used as a delegation identifier, this meansthat it is unique per delegation (from a certain delegating MR). Thus,if a delegating MR delegates multiple delegations to the same receivingMR, each of these delegations will involve a unique delegation MR-ID(and preferably, but not necessarily, unique credentials, e.g. apre-shared key). A delegation would be identified, e.g. during update orrevocation, by the delegation MR-ID in combination with the identity ofthe delegating MR. As a consequence the HA will perceive the receivingMR as multiple MRs—one for each delegation MR-ID. This in turn meansthat multiple MR-HA tunnels have to be established and multiple BindingUpdate procedures have to be used. A separate delegation ID would notserve any purpose in this case. All in all, this would be simple, butrather inefficient.

If the delegation MR-ID is used as a pure MR identifier, multipledelegations from a certain delegating MR to the same receiving MR woulduse the same delegation MR-ID (and the same credentials) in thedelegation contexts. If no separate delegation ID is used, a delegationwould be identified by the combination of delegation MR-ID, prefix(es)and the identity of the delegating MR. The HA would perceive thereceiving MR as a single MR with multiple delegations. That is, a singleMR-HA tunnel could be used and a single Binding Update procedure wouldencompass all the delegated prefixes. A disadvantage is that if a HAwants to reject the “part of” a Binding Update that pertains to onedelegated prefix, but accept the “part” that applies to anotherdelegated prefix, more refined result indications would be needed in theBinding Acknowledgement. Such a result indication could e.g. be realizedthrough a status code that means “Binding Update accepted for a subsetof the delegations” combined with a new mobility option that wouldidentify either the accepted delegations or the rejected delegations.One reason for such a part acceptance could be that the lifetime of oneof the delegations has expired but not for the other(s). Similar refinedindications could also be used in a BE, when a HA uses a BE forrevocation of one or more delegations.

Another potential consequence of identifying a delegation by thecombination of delegation MR-ID, prefix(es) and the identity of thedelegating MR would be that care has to be taken to ensure that adelegation update is not confused with a creation of a new delegation.If, for instance, a delegation update contains the old delegation MR-IDand only a new prefix to be added, this could potentially (although therisk would be small) be confused with the creation of a new delegationfor the new prefix, unless the message contains an explicit indication(e.g. a flag or separate message types) of whether it signals an updateof an existing delegation or a creation of a new one. Another way toavoid the confusion is to always include in the message the delegationMR-ID, the identity of the delegating MR and the current prefixes of adelegation to be updated (as a clear identification of the concerneddelegation), followed by the actual updates.

Introduction of a separate delegation ID has some, but small, impact onthe solution's properties for the case where the delegation MR-ID isused as a pure MR identifier. In this case a delegation would beidentified by the combination of delegation MR-ID, delegation ID and theidentity of the delegating MR or, provided that the delegating MRensures that the delegation ID is unique among all its delegations (i.e.even across multiple receiving MRs), the combination of delegation IDand the identity of the delegating MR. A single MR-HA tunnel and BindingUpdate procedure would still suffice for all delegations, but thedelegation identification in the refined result indication in the BAwould be different (as described above) when the delegation ID isintroduced.

When a delegation ID is used there is no risk of confusion of creationand update messages and the same message type could, if desired, be usedfor both actions, without explicit indication of action type.

All the above issues concern situations when a delegating MR issuesmultiple delegations to the same receiving MR. But why would adelegating MR do that instead of keeping everything in a singledelegation—especially since an existing delegation may be updated, e.g.with an additional prefix? A reason for issuing multiple delegations tothe same receiving MR may be that the delegating MR wants differentdelegation properties to be associated with different delegatedprefixes. As an example, a delegating MR that wants to delegate theright to use a second prefix to the same receiving MR may want to have adifferent lifetime for the delegation pertaining to the second prefix.This can be achieved by issuing a new delegation for the second prefix,but not by updating the old delegation with the new prefix.

From the above description of embodiments of the present invention it isapparent that there are several nodes that are involved and interact inthe prefix delegation process. These nodes are the delegating MR, thereceiving MR and the HA. These nodes must be adapted to support prefixdelegation. The person skilled in the art will appreciate that thisadaptation in most cases involves loading new software into thedifferent nodes to support the new information exchange between thenodes that is required to implement the prefix delegation. The personskilled in the art will also appreciate that this adaptation of thenodes also can be realized by means of hardware circuits or firmware.The software, firmware or hardware circuits that are included in the HA201, receiving MR 202 and delegating MR 203 to implement the prefixdelegation are illustrated schematically as blocks denoted 201 a, 202 aand 203 a respectively in FIGS. 2-7. Furthermore a communicationsinterface of the delegating MR 203 and a communications interface of thereceiving MR 202 for establishing a communications connection betweenthe delegating MR and the receiving MR 202 according to the presentinvention are illustrated and denoted by 203 b and 202 b respectively.

As was discussed above, the present invention may be used in the VANillustrated in FIG. 1. The present invention may also be used in a VAN101′ illustrated in FIG. 8. The VAN 101′ in FIG. 8 is similar to the VAN101 in FIG. 1. The difference is that the mobile routers 104, 105 havedifferent HAs 112 and 112′ located in different home networks 111 and111′.

The present invention may also be used in a Personal Area Network (PAN)with one or several MRs that provide the external access to the PAN. APAN may for instance comprise the gadgets/devices that a user iscarrying with him/her or the network within the user's personal car.Examples of two different PANs 301 and 301′ are illustrated in FIGS. 9and 10. The PANs 301 and 301′ include a switched Ethernet network 302(illustrated schematically as a circle in FIGS. 9 and 10) based on forinstance Bluetooth running a PAN profile. The PANs 301 and 301′furthermore include a number of nodes in FIGS. 9 and 10 four exemplarynodes are shown: a mobile phone 303, a laptop 304, a digital camera 305and a PDA 306. In these examples the mobile phone 303 and the laptop 304act as MRs, which means that they act as routers within the PAN andprovide access to an external network 307. In FIGS. 9 and 10 it isillustrated schematically that the mobile phone 303 provides a WCDMAaccess 308 to the external network 307 and the laptop 304 provides aWLAN access 309. The mobile phone 303 and the laptop 304 are as MRs alsoresponsible for mobility management of the PAN. As in the VAN exampleswith multiple MRs scenario illustrated in FIG. 1, the MRs in the PAN mayshare the same HA 310 and the same prefix from the address range oftheir home network 311, as illustrated in FIG. 9. However, in the PANscenario it is more likely than in the VAN scenario that different MRshave different HAs 310 and 310′ in different home networks 311 and 311′and thus different prefixes, which is illustrated in FIG. 10. The twoaccesses 308 and 309 may well use different operators and thus differentsubscriptions. As in the previously described VAN scenarios the MRs 303and 304 need to establish a bidirectional tunnel to the home agent foreach available external access.

In a multi-MR, multi-MNP scenario the present invention can be used toallow flow management, involving access selection per flow, to beindependent of MR selection and source address selection, while stillavoiding ingress filtering problems. This is achieved by ensuring thatall MRs in a moving network support all (and thus the same) prefixes.All MRs may by means of the present invention establish tunnels over alltheir accesses to all HAs. If an MR, for example, has three accesses andthere are two involved HAs (for all the MRs in the moving networktogether), the MR will establish six tunnels. Then the MR can sendpackets over any of its accesses to any of the HAs that are used in themoving network. Provided that the other MR(s) establish correspondingarrangements, this gives the MR complete freedom to select accessindependently of source address selection. This approach does notrequire forwarding of packets between MRs, unless an external accesslink that is only available from another MR is selected for an outboundpacket, according to the flow management policies.

Accordingly the present invention may be used to providecross-delegations in the moving network 101′ in FIG. 8 such that all MRs104 and 105 in the moving network support each other's prefixes. Whenthe MR 105 receives an outgoing packet it uses its access selectionpolicies to determine which one of the external accesses that areavailable in the moving network that the packet should be forwardedover. If the selected access is available only through the other MR 104,the packet is forwarded to this outgoing MR 104. Otherwise, if theselected access is available in the MR 105 itself, then the MR 105 isthe outgoing MR. The outgoing MR checks the prefix of the packet'ssource address and forwards the packet over the selected access throughthe tunnel to the HA that is associated with the concerned prefix. Ifthe outgoing MR is another MR than the MR 105, it uses its accessselection policies to determine which external access to forward thepacket over before checking the prefix tunneling the packet to the HA.

As mentioned above an advantageous property of the present invention isthat it can be used to harmonize the prefix usage so that all MRs in amoving network consistently support the same set of prefixes. To achievethis each MR in a moving network should delegate the right to use eachof its prefixes (for which it is a primary prefix holder) to all otherMRs in the moving network that do not support the prefix. This genericrule may however result in redundant delegations. Consider for instancea scenario with three MRs—MR1, MR2 and MR3—in a moving network.Initially MR1 is a primary prefix holder of prefix P1 and MR2 and MR3are both primary prefix holders of prefix P2. According to the abovegeneric rule MR1 would delegate the right to use prefix P1 to MR2 andMR3 and MR2 and MR3 would both delegate the right to use prefix P2 toMR1. The double delegation to MR1 of the right to use prefix P2 makesone of the delegations redundant.

To avoid redundant delegations it is preferable to use delegationprocedures that are initiated with phase 1 in which a receiving MRrequests prefix delegation as described above. In the scenario examplewith three MRs and two prefixes this would mean that MR1 would requesteither MR2 or MR3 to make it a secondary prefix holder of prefix P2(i.e. to be delegated the right to use prefix P2), while both MR2 andMR3 would request MR1 to delegate the right to use prefix P1.

Redundant delegations can also be avoided without using phase 1. Asimple way would be that the potential receiving MR rejects thedelegation, e.g. in step 209 in FIG. 4, if it already is a secondary (orprimary) prefix holder of the concerned prefix(es). In combination withthis approach it may be preferable to let a MR use a random delay beforedelegating the right to use a certain prefix after discovering anotherMR in the moving network that does not support the prefix.

Although avoiding redundant delegations is generally preferable, one mayalso see advantages in such redundancy. For instance, if, in the abovescenario example with three MRs and two prefixes, MR1 has receiveddouble delegations of rights to use prefix P2 and one of thesedelegations times out (or is explicitly revoked/deleted), e.g. becauseMR2 or MR3 is powered off, then MR1 can still keep supporting prefix P2without interruption based on the other delegation.

In addition the prefix harmonization that can be achieved in a movingnetwork by means of the present invention makes it possible to benefitfrom the advantages provided by a multi-homed moving network, e.g. pathredundancy, since it provides the possibility to move communication fromone MR to another without changing the MNN address for thecommunication. If it would be necessary to change the MNN address forthe communication then most sessions would be broken. This prefixharmonization can be achieved even when the different MRs are usingdifferent HAs.

The nature of a moving network is often inherently dynamic. This doesnot only mean that available external accesses come and go as the movingnetwork moves, disconnects and reconnects, but also that the movingnetwork may split into separate moving networks or merge with anothermoving network and that the MRs that are present in the moving networkmay change at any time. As an example, the PAN 301 in FIG. 9 may splitinto two moving networks or “sub-PANs” where a first sub-PAN comprisesthe mobile phone/MR 303 and the PDA 306 and the second sub-PAN comprisesthe laptop/MR 304 and the digital camera 305. The two sub-PANs may thenalso merge into a single PAN, i.e. changes between these two conditionsmay occur dynamically. The reason for splitting or merging the PAN 301may be that even though the user more or less brings a number of devicesalong in his/her daily life, the devices may not be close enough to eachother to communicate at all times. A couple of devices may for instancebe left at the user's office desk, while others are brought to ameeting. In another example some of the devices in the user's PAN moreor less never leave home. They are part of the merged PAN together withthe user's mobile devices when the user is at home, but when the user isaway from home his/her home devices form one sub-PAN and his/her mobiledevices form another sub-PAN. Still, the home devices may stay connectedto a network infrastructure to allow communication in general andspecifically to allow the user to communicate with the home devices,e.g. for retrieving information (e.g. from a surveillance camera) or forremote control (e.g. house heating or the kitchen oven).

In the case of a VAN on a train splits and mergers of the VAN may occurwhen cars are connected and disconnected in various combinations. Inorder for each car to be able to function independently, each car mayhave one or more MRs and one or more external network accessesconstituting an independent moving network. When two cars are connected,their respective moving networks are merged (through e.g. a simpleconnector or a layer 2 bridge device). Thus, the network devices in allthe cars of a train typically constitute a single moving network withmultiple MRs. When a car is disconnected from a train, the movingnetwork is divided into two moving networks, one in the disconnected carand the other one in the remaining car(s). The MRs of the moving networkbecomes resources that are shared by the MNNs, i.e. the MRs togetherserve the moving network, providing the MNNs with external networkaccess (e.g. through WCDMA, GPRS and/or a satellite link).

The present invention can be used to maintain prefix consistency inmoving networks that go through splits and/or mergers. Dynamic eventssuch as splits and mergers can cause MRs to change prefixes or adopt newones in order to reestablish prefix consistency after a dynamic event.These prefix changes involve algorithms/principles for prefix selection.When multiple HAs and delegated prefix rights are introduced, the prefixselection algorithms/principles must be slightly adapted to take intoaccount the concepts of primary and secondary prefix holders.

In general it is assumed that a MR advertises all the prefixes that itsupports in the moving network, including both the prefixes for which itis a primary prefix holder and the ones for which it is a secondaryprefix holder. It is however possible to use the present invention suchthat a MR only advertises prefixes for which it is a primary prefixholder, but not the ones for which it is a secondary prefix holder. Analternative would however be to associate an indication with each prefixin the Router Advertisement message indicating whether the advertisingMR is a primary or secondary prefix holder for the prefix. Thisindication could be included in the Prefix Information option for eachprefix in the Router Advertisement message. Backwards compatibilitywould be achieved if the “Reserved1” field or “Reserved2” field is usedto include the indication. Another way to introduce the new indicationin a backwards compatible manner would be to introduce a new option forthe Router Advertisement message, containing either both a prefix andits associated indication or only an indication. In the latter case theorder in which the options appear in the message would indicate whichprefix a certain indication is associated with. This method is backwardscompatible, because all nodes should silently ignore any options they donot recognize in a received Router Advertisement message. An advantagewith a new indication in the Router Advertisement message would be thata MR that wishes to request to be delegated the right to use a certainprefix easier can identify the MR that is responsible for the prefix(i.e. a MR that is a primary prefix holder for the concerned prefix),which is thus the one to send the request to.

The above embodiments of the present invention were described inconjunction with the NEMO Basic Support protocol, which is defined onlyfor IPv6. However, the principles and mechanisms of the NEMO BasicSupport protocol, as well as the mechanisms of the invention, can begeneralized to work also in an IPv4 environment. For the NEMO BasicSupport protocol this means that the protocol should be specified interms of extensions to MIPv4 as described in “IP Mobility Support forIPv4” by C. Perkins et al. published in August 2002 as a Request ForComments (RFC) 3344 by the Internet Engineering Task Force instead ofextensions to MIPv6 as described in “Mobility Support in IPv6” by D.Johnson et al. published in June 2004 as RFC 3775. Adaptation of thepresent invention to IPv4 implies that all IPv6 prefixes and addressesare replaced by IPv4 prefixes and addresses. Using ICMPv4 RouterAdvertisements may also be useful in order to facilitate that MRsdiscover each other and the prefixes they support. A possiblealternative to specifying the NEMO Basic Support protocol in terms ofMIPv4 extensions is to use an available mechanism for running MIPv6 overIPv4 (such mechanisms are being worked on in the IETF) to run the NEMOBasic Support protocol in an IPv4 environment. If the interior of themoving network is based on IPv6, no further adaptation is needed. If theinterior of the moving network is based on IPv4, the rest of the abovedescribed adaptations (i.e. excluding specifying the NEMO Basic Supportprotocol in terms of MIPv4 extensions) are needed.

In the drawings and specification, there have been disclosed typicalpreferred embodiments of the invention and, although specific terms areemployed, they are used in a generic and descriptive sense only and notfor purposes of limitation, the scope of the invention being set forthin the following claims.

1. A method for prefix management in a first mobile router of a movingnetwork, which first mobile router is assigned a first prefix for usewhen passing traffic to and from a home agent with which the firstmobile router is associated, which method comprises the steps of:establishing a communications connection with a second mobile router ofthe moving network; delegating the right to use said first prefix tosaid second mobile router by: transferring first prefix delegationinformation to said home agent; and transferring second prefixdelegation information to said second mobile router over saidcommunications connection, which first and second prefix delegationinformation includes first and second authentication informationrespectively that may be compared to verify that the second mobilerouter has the right to use said first prefix.
 2. The method accordingto claim 1, wherein said step of establishing a communicationsconnection with the second mobile router includes: determining a trustlevel of the second mobile router based on identity information receivedfrom said second mobile router; and establishing the communicationsconnection as an IPsec connection or other secure communicationsconnection, and wherein said step of transferring first prefixdelegation information to said home agent includes transferringinformation on said determined trust level to said home agent.
 3. Themethod according to claim 1, further including the step of receiving arequest for a delegation of said first prefix from said second mobilerouter and wherein said step of establishing said communicationsconnection is performed in response to reception of said delegationrequest.
 4. The method according to claim 1, wherein said first prefixdelegation information is transferred to said home agent by means of aBinding Update.
 5. The method according to claim 1, wherein said secondprefix delegation information is transferred to said second mobilerouter using the File Transfer Protocol, FTP, the Personal Area NetworkManagement Protocol, PMP or the Hyper Text Transfer Protocol, HTTP. 6.The method according to claim 1, including the further step of revokingthe delegation of said first prefix to said second mobile router bysending a revocation message to said home agent.
 7. The method accordingto claim 1, including the further step of updating the delegation ofsaid first prefix to said second mobile router by sending a firstupdating message including changes to said first prefix delegationinformation to said home agent and sending a second updating messageincluding changes to said second prefix delegation information to saidsecond mobile router.
 8. A method for prefix management in a secondmobile router of a moving network, which method comprises the steps of:establishing a communications connection with a first mobile router ofthe moving network, which first mobile router is assigned a first prefixfor use when passing traffic to and from a home agent with which thefirst mobile router is associated; receiving second prefix delegationinformation from said first mobile router over said communicationsconnection delegating the right to use said first prefix to said secondmobile router, which second prefix delegation information includessecond authentication information that may be compared to firstauthentication information to verify that the second mobile router hasthe right to use said first prefix; sending a request for a prefixdelegation utilization to said home agent which utilization requestincludes said second authentication information; and establishing abidirectional tunnel for passing traffic using said first prefix betweensaid second mobile router and said home agent.
 9. The method accordingto claim 8, further including the step of including said first prefix ina Router Advertisement of the second mobile router after establishmentof the bidirectional tunnel.
 10. The method according to claim 8,further including the step of sending a request for a delegation of saidfirst prefix to said first mobile router and wherein said step ofestablishing said communications connection is initiated from said firstmobile router in response to reception of said delegation request. 11.The method according to claim 8, wherein said steps of sending a requestfor prefix delegation utilization and establishing the bidirectionaltunnel includes performing an Internet Key Exchange procedure with thehome agent, sending a Binding Update to the home agent and establishingthe bidirectional tunnel according to the NEMO Basic Support protocol.12. A method in a home agent having an associated first mobile router ofa moving network, which first mobile router is assigned a first prefixfor use when passing traffic to and from the home agent, which methodcomprises the steps of: receiving first prefix delegation informationfrom said first mobile router delegating the right to use said firstprefix to a second mobile router of said moving network, which firstprefix delegation information includes first authentication information;receiving a request for a prefix delegation utilization from said secondmobile router which utilization request includes second authenticationinformation; authorizing the prefix delegation of said first prefix tosaid second mobile router if a comparison of said first authenticationinformation and said second authentication information verifies that thesecond mobile router has the right to use said first prefix; andestablishing a bidirectional tunnel for passing traffic using said firstprefix between said second mobile router and the home agent if saidprefix delegation was authorized.
 13. The method according to claim 12wherein said step of receiving first prefix delegation information fromsaid first mobile router includes receiving information on a determinedtrust level of the second mobile router.
 14. The method according toclaim 12, wherein said first prefix delegation information is receivedfrom said first mobile router in a Binding Update.
 15. The methodaccording to claim 12, wherein said steps of receiving a request forprefix delegation utilization, authorizing the prefix delegation andestablishing the bidirectional tunnel includes performing an InternetKey Exchange procedure with the second mobile router registering thesecond mobile router in the home agent through a Binding Updateprocedure and establishing the bidirectional tunnel according to theNEMO Basic Support protocol.
 16. The method according to claim 12,including the further step of revoking the delegation of said firstprefix to said second mobile router, which revocation step includesclosing said bidirectional tunnel.
 17. The method according to claim 16,wherein said revocation step is performed in response to reception of arevocation message from the first mobile router.
 18. The methodaccording to claim 1, wherein said first and second authenticationinformation each includes a delegation MR-ID which identifies thedelegation of the right to use the first prefix to the second mobilerouter.
 19. The method according to claim 18, wherein at least one ofsaid first and second authentication information includes a set ofcredentials such as a pre-shared key, a certificate, a password or aPIN-code generated by said first mobile router and associated with saiddelegation MR-ID.
 20. The method according to claim 1, wherein thedelegation of said first prefix to said second mobile router isassociated with a lifetime of the delegation which indicates the periodduring which the delegation is valid.
 21. The method according to claim1, wherein said first prefix delegation information further includes thefirst prefix and/or an identity of the first mobile router.
 22. Themethod according to claim 1, wherein said second prefix delegationinformation further includes the first prefix and/or an address of thehome agent.
 23. The method according to claim 1, wherein said secondmobile router belongs to another home agent than the first mobilerouter.
 24. A first mobile router of a moving network, which firstmobile router is arranged to be assigned a first prefix for use whenpassing traffic to and from a home agent with which the first mobilerouter is associated, the first mobile router comprising: acommunications interface for establishing a communications connectionwith a second mobile router of the moving network; and means fordelegating the right to use said first prefix to said second mobilerouter which means for delegating includes means for transferring firstprefix delegation information to said home agent and means fortransferring second prefix delegation information to said second mobilerouter over said communications connection, which first and secondprefix delegation information includes first and second authenticationinformation respectively that may be compared to verify that the secondmobile router has the right to use said first prefix and wherein thefirst and second authentication information comprise identityinformation associated with the second mobile router and a set ofcredentials associated with the identify information.
 25. The firstmobile router according to claim 24, wherein said first mobile routerfurther includes means for determining a trust level of the secondmobile router based on identity information received from said secondmobile router, wherein said means for transferring first prefixdelegation information to said home agent is arranged to transferinformation on said determined trust level to said home agent, andwherein said communications interlace is arranged to establish thecommunications connection as an IP Security connection or other securecommunications connection.
 26. The first mobile router according toclaim 24, which first mobile router further includes means for revokingthe delegation of said first prefix to said second mobile router whichmeans for revoking are arranged to send a revocation message to saidhome agent.
 27. The first mobile router according to claim 24, whichfirst mobile router further includes means for updating the delegationof said first prefix to said second mobile router, which means forupdating are arranged to send a first updating message including changesto said first prefix delegation information to said home agent and tosend a second updating message including changes to said second prefixdelegation information to said second mobile router.
 28. The firstmobile router according to claim 24, wherein the second mobile routerbelongs to another home agent than the first mobile router.
 29. A secondmobile router of a moving network, the second mobile router comprising:a communications interface for establishing a communications connectionwith a first mobile router of the moving network, which first mobilerouter is assigned a first prefix for use when passing traffic to andfrom a home agent with which the first mobile router is associated;means for receiving second prefix delegation information from said firstmobile router over said communications connection delegating the rightto use said first prefix to said second mobile router, which secondprefix delegation information includes second authentication informationthat may be compared to first authentication information to verify thatthe second mobile router has the right to use said first prefix, andwherein the first and second authentication information compriseidentity information associated with the second mobile router and a setof credentials associated with the identify information; and means forsending a request for a prefix delegation utilization to said home agentwhich utilization request includes said second authenticationinformation; and means for establishing a bidirectional tunnel forpassing traffic using said first prefix between said second mobilerouter and said home agent.
 30. The second mobile router according toclaim 29, further including means for including said first prefix in aRouter Advertisement of the second mobile router after establishment ofthe bidirectional tunnel.
 31. The second mobile router according toclaim 29, wherein said means for sending a request for prefix delegationutilization and said means for establishing the bidirectional tunnel arearranged to perform an Internet Key Exchange procedure with the homeagent, send a Binding Update to the home agent and establish thebidirectional tunnel according to the NEMO Basic Support protocol. 32.The second mobile router according to claim 29, wherein the secondmobile router belongs to another home agent than the first mobilerouter.
 33. A home agent arranged to be associated with a first mobilerouter of a moving network, which first mobile router is assigned afirst prefix for use when passing traffic to and from the home agent,which home agent comprises: means for receiving first prefix delegationinformation from said first mobile router delegating the right to usesaid first prefix to a second mobile router of said moving network,which first prefix delegation information includes first authenticationinformation; means for receiving a request for a prefix delegationutilization from said second mobile router which utilization requestincludes second authentication information; means for authorizing theprefix delegation of said first prefix to said second mobile router if acomparison of said first authentication information and said secondauthentication information verifies that the second mobile router hasthe right to use said first prefix; and wherein the first and secondauthentication information comprise identity information associated withthe second mobile router and a set of credentials associated with theidentify information; and means for establishing a bidirectional tunnelfor passing traffic using said first prefix between said second mobilerouter and the home agent if said prefix delegation was authorized. 34.The home agent according to claim 33 wherein said means for receivingfirst prefix delegation information from said first mobile routerincludes means for receiving information on a determined trust level ofthe second mobile router.
 35. The home agent according to claim 33,wherein said means for receiving first prefix delegation information isarranged to receive said first prefix delegation information from saidfirst mobile router in a Binding Update.
 36. The home agent according toclaim 33, wherein said means for receiving a request for prefixdelegation utilization, said means for authorizing the prefix delegationand said means for establishing the bidirectional tunnel are arranged toperform an Internet Key Exchange procedure with the second mobilerouter, to register the second mobile router in the home agent through aBinding Update procedure and to establish the bidirectional tunnelaccording to the NEMO Basic Support protocol.
 37. The home agentaccording to claim 33, wherein the second mobile router belongs toanother home agent than the first mobile router.
 38. A communicationssystem, comprising: a moving network including a first and a secondmobile router, and a home agent associated with the first mobile router,which first mobile router is assigned a first prefix for use whenpassing traffic to and from the home agent, which first mobile router isarranged to delegate the right to use said first prefix to said secondmobile router by transferring first prefix delegation information to thehome agent and second prefix delegation information to said secondmobile router, which first and second prefix delegation informationincludes first and second authentication information respectively thatmay be compared to verify that the second mobile router has the right touse said first prefix and wherein the first and second authenticationinformation comprise identity information associated with the secondmobile router and a set of credentials associated with the identifyinformation.
 39. The communication system according to claim 38, whereinsaid second mobile router is arranged to send a request for a prefixdelegation utilization to said home agent which utilization requestincludes said second authentication information.
 40. The communicationsystem according to claim 39, wherein the home agent is arranged toauthorize the prefix delegation of said first prefix to said secondmobile router if a comparison of said first authentication informationand said second authentication information verifies that the secondmobile router has the right to use said first prefix and to establish abidirectional tunnel for passing traffic using said first prefix betweensaid second mobile router and the home agent if said prefix delegationwas authorized.
 41. The communication system according to claim 38,wherein the second mobile router belongs to another home agent than thefirst mobile router.